Architectures for Fleet Management

With the increasing reliance on space systems for communications, the number of multi-satellite, multimission operators, in both the government and commercial sectors, is also increasing. To prevent the operations and maintenance costs from increasing linearly, or worse, with the number of satellites, operators are attempting to consolidate operations and maintenance across the satellite fleet. Different satellite generations and buses complicate this fleet view, and different ground control systems have differing capabilities in a fleet management environment. This paper examines the architectures of existing satellite fleet control centers, comparing capability, scalability, and maintainability. The paper then takes the lessons learned forward to propose architectural requirements for a future fleet management system and related satellite industry standards. Introduction Satellite fleet management is the control of multiple spacecraft from a single control system. Typically in the past, each satellite has been monitored and controlled by a dedicated control system. For multisatellite operators, this results in a proliferation of satellite control systems (SCS’s). If the satellites are acquired over time or are acquired from different vendors, the differences in the SCS’s increase the complexity of operations staffing, training, and ground system sustainment. There are two types of satellite fleets, multi-mission and multi-satellite/single-mission, although this differentiation can blur as the fleet ages. Commercial examples of multi-satellite/single-mission fleets are the Iridium and the Globalstar systems. Government or multi-government examples are the Global Positioning System (GPS) and the planned Galileo navigational system. Initially, all of the satellites in the multi-satellite fleet are similar, since they use the same satellite bus and payload. However, due to software uploads or satellite replacement, the satellites in these fleets will also tend to vary over time. The GPS system is nearing launch of its fourth generation of satellites, built by three different vendors, requiring the ground control system to accommodate significant variation in the satellites. The multimission fleet is exemplified by the National Aeronautics and Space Administration (NASA), National Oceanic and Atmospheric Administration (NOAA), and European Space Agency (ESA) earth-observing Montreal, Canada – May 17 – 21 2004 1 of 8 SpaceOps 2004 Conference satellites. Many telecommunications organizations are also operating different satellites with different payloads from one or more satellite vendors. Benefits from a Fleet Perspective Fleet management can be accomplished using multiple SCS’s hosted in the same control center, but there are drawbacks to this approach. Variation in the SCS’s and the satellites increases training and staffing requirements and reduces the flexibility of staffing. Computer equipment typically has a much shorter lifetime than a satellite mission, so the operations staff may need to be retrained on new ground systems as upgrades are completed. Controlling a fleet of satellites from a single unified system can provide many benefits to organizations with more than one satellite, and these benefits are supported by specific key elements of a fleet control system. Fleet Overview – Consolidation of status data on to a single display or set of displays allows one operator to monitor the operation of many satellites, without jeopardizing the health and safety of the satellites, This operator’s role is to monitor operations and assist in manual special operations, rather than to manually conduct routine operations. This decreases the number of operators required to staff an around-the-clock operations center. Fleet Data Model – Data is named, collected, and managed as a fleet, providing separate namespaces for each satellite, but allowing similar satellites to reuse display and procedure definitions without creating multiple copies and versions. Derived data can be calculated from a single satellite or across satellites for use in reports and displays. Consistent User Interface – Common displays and tools used across multiple satellites reduces the training requirements for operations and results in more flexible staffing. Shared Analysis Tools – Historical data can be accessed and analyzed across satellites with common tools for easier performance analysis and management reporting. Unified Automation Tools – A single procedure language allows automation of routine operations across the fleet that can be managed consistently by operations staff and eliminates the need for multiple experts on satellite-vendor-specific procedure languages. Automated operations can be planned and tested by experts offline during normal working hours. Global schedule – A schedule of operations for all satellites and facilities provides a unified schedule for operations staff as well as the opportunity to share ground facilities and equipment across satellites. For example, a single steerable antenna with associated RF and baseband equipment can provide a backup interface and second ranging station for multiple satellites. Two Architectures for Fleet Management Montreal, Canada – May 17 – 21 2004 2 of 8 SpaceOps 2004 Conference Two architectures have emerged for fleet control systems to provide these benefits. The first is a “system of systems” (SOS) approach that maintains a single satellite control system for each of the satellites under control and applies a fleet integration software layer that provides the fleet perspective, as illustrated in Figure 1. This approach has been used by at least one telecommunications provider and has been proposed as an approach for Galileo. Figure 1 System of Systems Approach SingleSat Control System SingleSat Control System SingleSat Control System Fleet Integration Software SingleSat Control View SingleSat Control View SingleSat Control View Fleet Control View The fleet integration software provides the integrated view of the system to fleet operators and spacecraft engineers. In some cases, all monitoring and control functions are performed at the fleet level, without directly using the individual SCS displays and procedures. In other cases, the fleet view is provided for the supervisory level, but automated and manual operations are carried out using the satellite-specific SCS. There are several advantages to this approach: It allows a progressive migration to fleet operations from individual SCS’s. It allows automated operations using the tested procedures (if any) provided by the satellite vendor. Montreal, Canada – May 17 – 21 2004 3 of 8 SpaceOps 2004 Conference Because the SCS systems are independent, they can typically be stopped, modified, and restarted without affecting other satellites under control, assuming the fleet integration software is written to prevent deadlocks. The difficulty with this approach is the complexity of the fleet integration software layer. The greater the variation in the underlying SCS’s is, the greater the complexity of the integration layer will be. The integration software layer is dependent not only on each SCS, but on each SCS version, creating complexity for system upgrades. In some cases, the underlying technology of a new SCS may make it impossible to bridge without impacting the interfaces to existing SCS’s. The fleet data model must be implemented completely in the integration layer, since the underlying SCS software contains no structures for multiple satellites. To fully achieve the benefits of a fleet management system with the SOS approach, many of the functions that exist in the underlying SCS’s will be duplicated and eventually obsoleted by the integration layer, including displays, data archival, procedure language, etc. Equipment sparing and systems maintenance personnel will have to be trained for all of the underlying computer system types. Another drawback to this approach is that each underlying SCS system must be maintained at least through the associated satellite lifetime. Since the typical telecommunications satellite lifetime is about 3 times the obsolescence lifecycle of computer systems, several upgrades may take place during the life of the satellite and may affect the integration software layer. In the worst case, the SCS may become unsupported. Because of this possibility, the connection layer protocol between the integration layer and each SCS should be based on highly interoperable standards supported at the operating system (OS) level, e.g. TCP/IP, since an SCS may be stranded on a particular equipment and OS version without the ability to upgrade other 3 party packages. Multi-Satellite Control System The second architectural approach to fleet management uses a control system that is inherently a multisatellite control system (MSCS), i.e. it contains the data models and internal architecture to support the key elements of fleet management. Multi-satellite capability has been demonstrated in some commercial off-the-shelf products, such as OS/COMET from Harris Corporation, and in some custom ground control systems, such as the control system for the Globalstar constellation. An important requirement for an MSCS is that it is easily adaptable to new satellite bus types. This is an important requirement for multi-mission fleets and frequently becomes a requirement for a long-term, multi-satellite/single mission fleet. Figure 2 illustrates the internal layering necessary to provide a consistent fleet-wide toolset for monitoring and control with adaptation for different satellite buses. Much of the adaptation can be data-driven, with definitions of telemetry items, telemetry packets, telecommand formats, and telecommand parameters controlling the telemetry and telecommand processing. A capability for software adaptation is also frequently necessary to handle different ground equipment Montreal, Canada – May 17 – 21 2004 4 of 8 SpaceOps 2004 Conference interfaces and ground-space protocol differences. This adaptability requirement is satisfied in the SOS approach by interfacing the fleet integration layer to an individual SCS. Figure 2 Multi-Satellite Control System CMD DB TLM DB CMD DB TLM DB CMD DB TLM DB CMD DB TLM DB 376 601 702 1300 Gnd/Space Protocol Gnd/Space Protocol Gnd/Space Protocol Gnd/Space Protocol Another key requirement for the MSCS is the independence of satellite control sessions, so that satellite processing can be stopped, restarted with changes, or added without affecting any other satellites. This requirement is normally met within the SOS approach by careful development of the integration layer to prevent deadlocks or side effects between SCS interfaces. Scalability is also a significant concern for fleet management systems. As the number of satellites in the fleet increases, the number of workstations and servers involved in management of the fleet increases. By design, software processes running on these workstations and servers must coordinate activities for the fleet, so the number of software process interconnections between workstations and servers can increase exponentially for a fleet management system. The internal architecture of the control system should provide proven scalability for the size of the fleet anticipated. Even though the SOS approach avoids this interconnection problem for the independent SCS’s, it does require proven scalability for the fleet integration software layer. Montreal, Canada – May 17 – 21 2004 5 of 8 SpaceOps 2004 Conference Sharing Ground Equipment One advantage for a fleet management approach is the possibility of sharing of equipment and operations staff across the fleet. There are several different models for the sharing of ground equipment, including dedicated strings, cross-strapped arrays of equipment, and remote linked equipment. These ground equipment models are illustrated in Figure 3. The illustration is simplified, since there are usually multiple pieces of equipment involved in satellite monitoring and control, e.g. modulators, demodulators, encryptors, decryptors, amplifiers, etc. It is meant to convey how the equipment is allocated for control. Figure 3 Ground Equipment Models